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ABSTRACT 


The design and implementation of an LALR(1) FORTRAN 
grammar nas Oeen described. Desian reauirements and 
Necommendations [ογ ϐ 168 byte microcomputer system, which 
woula allow the use of the FORTRAN orcarammina languaae as 
defined oy the arammar implementation, have been presented. 
The prooosed system consisted of tnree subsystems: a FURTRAN 
Some) ler cased on t^e grammar implementation which produced 
an intermediate lancuage» a linkina-=loader that eneoled 
inaependently comot!lec orogram units to oe linken, and ασ 
meceroreter that executed the intermediate larcuane on tne 


specific target machine. 
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Il. INTRODUCTION 


IS NES TORY OF THE FORTRAM LANGUAGE 


FORIRAN was produced in the late 1950's for use on Toy 
computers. With the backina of IBM, FORTRAN became wigcely 
Beceptec and was subsequently developed for many machines 
suring tne τους, The American National Standards 
Bammittee soecificaticn of FORIRAN in 1%06 [2] has araauallv 
become accepted and most oresent compilers conform to this 


Eramcornroc. 


- 


INE UD the committee |dgeveloced a draft proposed 
american National Standara FORTRANnN (4) as a reolacement for 
ο" original Standarc. fhe FURTRAN language aefinition 
Gescribed in the pronosed Standara included essentially al! 
features of the original Standard with the majer exception 
being the removal of the Hollerith data type. A numoer of 
additional capabilities including a character data type and 


file oriented input/outcut were also added to the lanauage. 


FORTRAN has made a significant contribution to computer 
"wechnology. its development provided 3 languace that was 
easily learned by a wige variety of people ara tnat was 
available for use on existing haroware. by provicine a 
packed statement form which did not rely on the presence of 


blanks, FORTRAN allowed more efficient storage of procrams 





and greater ease o Programming» Wytn tne use of the 
equivalence statement, the control of storage allocation vy 


the proarammer was permitted for the first time. [9] 


ο ο τς ου Ἰσασοἳ Cefinition, FURTRAN has become the 
standard scientific computer  lanauage. because of the 
portability of programs written in FORTRAN it has alse 
Decome a common IM SEE language that has been 
generateu ov languace processors and compilers, as well as 


umecof tne standard lanauages for proaram portability. 


Do MA ο an wiih MICRUCOMPUTER SYSTEYS 


Decent advances tm the corstruction of diaital circuits 
Ex resulted in the availability of low-cost LSI computer 
components. These components» 4nich include central 
processina umts. memory systems and peripherals tor 
eur /output, can be combined to form a digital comcuter 
KNOWN as a microcomputer. ασπρο number of apalıcatıon 
areas for microcomouters have been identified, such as 
intelligent termina!s, dedicated processors ana minicomouter 


Control tasks. (11) 


Ia contrast to the advanced technoloay utilized 1η 
microcomputer hardware, the software designea to support 
microcomputers has been slow in developina. A great deal of 
applications work nas been done airectly in machine languaae 
since microcomputer confiaqurations have often lacked tne 


memory and input/output espocııy to .spbport erogran 





development in assembly language. [he use of assembly 
language has veen supported by many microcomnuters and when 
combined witn a text editor and  debugaina aics formed 3 


useful packace for the proarammer. To date, very few hian- 


level languages have been developed Tor use on 3 
microcomputer system, Sois Currently the only nYon- 
level microcomputer systems programming languace which 1S 


widely used. 


Nath the expanding numoer Of aco lrcat tons tor 
microcomputers, nig^-level languaces must assume an 
increasinalv imoortant role 1n the develooment oF software 
fem use on microconputer systems, An tmolementation of tne 
FORTRAN lanauage τοπ be a valuable adcition to the h1an=- 
level languaces thet can be utilized TODAmMCIOCCOhDU rer 


software support. 


We purpose of this paper is to describe the desıen and 
implementation of an LALR(1) FORTRAN grammar for use with a 
self-hosteu compiler. An overall system design to ουσ ορ 
the FORTRAN Jlanquage on a microcomouter system is also 


oescrived. 


C. MOTIVATION FOR An LALR(1) GRAMMAR 


Une of the major techniques used in current compiler 
construction is based on work done by Knuth (8], wno 
developed deterministic parsing algorithms for the left-to- 


right translation of languages defined by LR(k) grammars. À 


10 





grammar is LR(k) if each sentence it generates can be parsed 
from left to riaht in a single scan with at most k looxanead 


symbols. 


LH(k)  arammars have several advantages. They are 
unamoiguous. onstruction L alaorithms E US {ος suse ass 
of arammar tnat can buila parse action tables. A parser can 
use the tables procuced by the analyzer to cetermine if 


language statements defined oy the arammar are well-formed. 


LR(k) grammars always reauire a lookahead of κ Symbols 
for tne parser to determine the next State. Lat r(«) 
A amars Jiffer fron το that ΤΕ lookanead 18 only 
performed when necessary, thus producing much smaller oarse 
taoles. (ne largest class of currently implementacie ἱπέίκ) 


Grammars are LALR(1). 


An efficient oarser can oe written to ιηπῖργογοῖ parse 
Ec tables for LALR(1) grammars bij. The garser is a 
table-ariven oushdown automaton thet assumes a seauence of 
states (shift, reduce, accept, or error) while scannina tne 
input. Decisions are basea on the next input symbol and 
information accumulated on a parse stack. The final state 


inacicates whether the input was well-formed. 


The availability of such an LALR Parser Generator [10] 
for use in developing a FORTRAN grammar was the major factor 
1n determining the method of constructing a comoiler for use 


in the implementation οί the FORTRAN language on a 


13 





microcomputer system. Tne LALR Parser program accepts a 
Backus Naur Form (BAF) grammar definition as input, ana tne 
number of lookaheads allowed, and aetermines if the arammar 
is  amoiguous. If the grammar is acceptaple then Darse 
EIxcscanecsphseducego that can be used with a parser, and 
Symtactic and semantic analyzer routines, to provide the 
basis for the systematic construction of a compiler. Tne 
perse tables that are produced are compatiole with tne PLM 
orogrammina lanauage but can be modified for use witn other 


lanquages. 


The LALK Parser Generator was instrumental de tne 
mevelooment of the large aramnar necessarv for FuPIPA' since 
GNF sefinitions could ce testea and debugged ine fe ment eal y 


as tne arammar was develoren, 


le 





Δ. ΙΟ“ »ΓΕΕΙΣΙΓΆΤΙ͂ΟΝ AND DESIGN 


E INTRODUCTION 


This chapter describes the reauirements, goals, and the 
design decisions considered during the cevelopment of the 
meer (1) FORTRAN grammar. In aadition, suagested extensions 


to tne Grammar are ıncludeo. 


ihe final κο pass version of the LALR(1) FURTRAR 
Eno3nmar Sion σος Ἱῃπ ἄρροποισὸος A and &. The syotax of 
the FOÜxIRAN statements that this crammar cefines is Included 
in the 1970 draft proposed American Nationa! Standard 
EORIKAN. The few deviations from the proposed Standsra are 
Ported ın the "Statement Restrictions” section ın this 


Chapter. 


See ΟσΑΜΜΑΠπ SPECIFICATION 


me synta Of) individual FORTPAN Statements and their 


o 


correct Ordering within program -units described ames 
proposed Standara were used to form the basis of tne grammar 
design. tat should pe noted that the grammar aeveloped to 
Gefine the proposed Standard also Svntactıcally vefines the 
1966 ANSI Steanaard FORTRAN. Not considered in tne design of 


the grammar were languaae extensions that have been mace to 








ANSI Standard FOKTRAN by language processors; unless they 


nave been included in the proposed Standard. 


C. GRAMMAR DESIGN 


FORTRAN as described in Refs. d ana U has been 
considered an inherently  ampiguous lanauage. LOTO ta 
completely define the syntax of the language an ambiaucus 


ος 


ct 


grammar is requirec. Since σα μετ Ὡρδπποςς mus 
unamoidguous by definition; [ws ρα ο ον, created 


problems during the cevelooment of the crammar. 


Ma tre sesion of tne arammar two »pCÓroacnes were taven 
Mo rder to solve these problems. First, consiceration was 
given to exoandina the grammar to define more than the 
syntax allowed when compensating actions could oe pertormecd 
in the semantics of a compiler implementing the grammar. 
Second, 1 f that approacn failed then tne grammar was 
restricted to aefine only a sunset of the syntax of tne 


lanquage. 


il. Design Goals 


The design aoals for the LALK(1) FORTRAN grammar 
were: (1) to adhere as closely as possible to the proposed 
ANS  Standara requirements o the FORTRAN lanquace 
definition, (2) tO maintain ë Overall Simone Cc 1.ty wel me time 


grammar and (5) to develoo a crammar small enouan to te 





utilized in 8 self-hosted compiler tor a Mierocomputer 


System with 16K bytes of memory. 


cae Tokens 


The tokens in the initial grammar desian consisted 

of special characters, reserved words, ar identifiers, 4 

statement label, a format Impar, ana. character, integer» 

real and double crecision constants. Ας the arammar was 
ο p . 

developed It was necessary to create statement termination 

array IMSS eT cexponpentxMatron ooerator and concatenation 


Meerator tokens |n orcer to resolve ampigun1ties. 
Θα reserves orgs 


ο ο ο ο Γρςοσοςοςυ ze FORTRAN key words, such as 
DIMENSION, COMMON, READ, etc.» the use of reserved words was 
required in the honeugacgedet3nit!|on. In the ANSI ana 
pronosed ANS Standara FORTRAN key words were not reserved 
and could also be useo as identifiers. However» in orger to 
Somrorm to normal Grammar techniques reserved woro toxens 
were created toccdgystugngulsh them from identifiers. In 
ντου to the FORTRAN key words the logica! constants 
Blur. and .FALSE., the relational operators  .Fü., ο, 
GE., E al and the locical operators .AND., 
Bigs eng .0R. were included as reserved words for ease in 


later implementation cf the grammar. 


p 





De Seatement lercrmınatıcon 


Ihe FORTRAN lanauage does not have a special 
Bendg-of-statement" delimiter equivalent to the Derio το 
POSOL or the semicolon in ALCOL: nme in order ζο 


"enge 


terminate each statement gefinition in the grammar an 
ps tatement" token was created. Without this token, the 
moe Farser Generator was unable to differentiate between 
individual statements in tne | anauage. The use of 15 
token must ce imolemented in any compiler that utilizes tne 


grammer but Should’ ne transparent to the user ort tne 


compiler. 
Ge. Statement Labels 


eR CeCi l τοῖς "statement label” was used to 
define the statement Pace S saiven to specific Statements. 
However, references to statement labels within a Statement 


(eeq.er GO TO 10) were definea as integer constants. 
gc »ceclal| “Characters 


Durina the development of the grammar the 
initial set of special rare caused ambiguities in the 
definition of an expression. Tne differences in the use of 
the ma) to) lcact ton operator * ana the exponentiation 
operator ** could not be resolved. A similar problem was 
encountered with the civide operator / and tne concatenation 


operator //. lt became necessary to create additiona! 


lo 





tokens for the exponentiation operator and the concatenation 


operator. 
e. Format Inout 


Mem format input” token was includes Tin the 
grammar design to allow format statements to be handleao in 
mere semantics of a compiler implementina the arammar, rather 


than in the grammar. 
f. read Paren 


A major problem was encountered up αθνθ]ορίΏο 
the arammar to define the FurfRäN reaa statement, Ina 
Sax of the unformatted read statement „as Ptedu ( «control 
morormation Iıst> J, while the syntax of the formatted read 
statement was READ <format>. ΠΕΠ Goth Ene fortart ana the 
Slot rol imtöormatıon Hist "allowed to he an exeressycn, a 
description of the syntax of the two read staterents became 
KEAD ( <expression> ) and READ <expression>. Since tne 
expression T included a rule that Stated «expression»? 
23= ( «expression? ) there was no way for an LALk(1) aramrar 
to unambiquously define both types of read statement. To 
solve this problem a "read paren" token was created to 
detine the beginning of an unformatted read statement. 
Although it is syntactically correct to parenthesize the 
mormat in the formatted read, in utilizina the grammar the 


design imposes the recuirement tnat a parenthesis following 


ee 





une READ automatically wmaicates an unformatted read 


statement. 
e ο οι Ἵσρο and Array identifiers 


Identifiers were initially desianeo to be any 
sequence of cone to six letters or numbers beginning with a 
letter, which was not — word. However; a proulem 
was encountered ym differentiatina between function 
references and array element references. Pes max dct 
as defined π.δ proposed Standard consists of an 
identifier followea by a parenthesized list of expressions, 
Bee xamole Alos,3r¢) and MAK(6,3,2e). Piss 1a Order o 


resolve this croolem an array iqentifier token was createc. 


VIStTINQUISHINGA between 1yaentifiers and array 


Edemtiftiers remains a nontrivial problem and must be hanaled 
οἱ. της semantics. Decendina on the technique used it mav 
impose the rpedurement that arrays cannot be referenced 


por to their definition in a dimension statement. 
s Exoressions 


The initial crammar design included the FURTRAN 
arıtnmetic, character and loaical expressions as separate 
entities. Tnese expressions are each constructeu usina 
ıdentical operands ~ identifiers, array element references 
amd function references. fhe specific tybe of each operand 
(character, Integer, etc.) must be examined in orger to 


determine whether it 15 valid för use mn a Dart ou lar 


18 





expression. The use of these identical operands again 
caused the arammar to be ambiquous. Ihe solution was to 
define one aeneral excression for overall use in the FORTPAN 
grammar. The rules that were develooed for this expression 
gefinition enforce operator precedence for each type. Tne 
Amantes of a compiler that uses such a grammar must be 
responsiole for determining what specific type of expression 
IS oeıng useo, and whether the operands are valia within 


Ehat type of expression. 


Another orotlem encountered in t^e expression 


definition WAS in enforcince DarentnesiZec express*|*ons as 


reauirec 1n some FORKTRAY statements. Tne Syn tax oT d^ 
expression οι οσας t^e rule «expression? Pr 
Kexpression>). Ihis Fesulrted η the reduction of a 


parentnesized expression to an exoression prior to its use 
in a statement. In oraer to enforce à  bDarenthesize-J 
expression tne rule was mogified as follows: 

<expression> ;:= <paren expression? 

«paren expression? ::- ( «expression? ) 
The second rule coulda then be used in any statements where 


parenthesizead expressions were required. 


ue Complex Constant s 


A furtner example that illustrates the problems 
encountered in constructing an LALRH(1) grammar is the 


definit ion required for a comolex constant. Syrtacticaiives 


159 





complex constant wes defined as ( «real constant» , «real 
constant > jus However, this definition could not oe useu in 
the grammar. Examination of the following grammar rules is 


necessary in order to understand tne oroblem: 


Scomplex constant» : (MHeresi constant? y; 


<pea! constant> ) 


«return statement? 7; RETURN <exoressi on 2 


<excression?> ::= <constant> 
«παρα exvoressior> 


earen expre Sion? 1:2 ( *axpression» ) 


SGGiniGtante .:= Sreal constant > 


Based on tnese arammar rules the pesinnina of one 
oerıvatıon for the return statement was RETURN f <real 
constant>. Uurina tne parsina of this statement with a left 
parenthesis and real constant on the stack tne Lang rarser 
Soma not determine if the real constant shoulda ke reducec 
to 3 Constant for eventual use in the return statement, or 
whether to stack a corma for eventual use in aàa complex 


eomstant. 


In attemoting to overcome the problem several 
alternative rules were examined for the complex constant 
COn tion that produced similar ambiguous results. The 
minal unambiguous definition was as follows: 

<complex constant> ::= <complex heaa> <expression> ) 
«complex head» ::= ( <expression> , 


These rules recutre the semantics CO gaeterminre et tne 


lU 





expressions in the complex constant definition are Lae toc t 


real constants. 


E InBut/Q0utrsut Specificatıon 


Ihe syntax of the 8“FURTRAN input/output statements 
included a large number of input/output specifications 
associated with each statement, including unit numbers, 
error specifiers and file specifiers. The ordering of tnese 
specifers and the specific Poets out mut specifications 
allowed with each statement were initially included in the 
grammar design. However, oue to tha large number of arammar 
rules reguired to enforce this syntax a general Ircut/cutout 
specification replacec tnem in πο tina) Oratmar. [has 
requires the interoretation οἱ seecii re που ο πρωι 


Beecifiers for the inout/output statements tn the semantics. 


ος Seatementsnestrictıons 


The grammar for the individual FURTRAN statements 
νι. ridinally desıcneg to strictly enforce the syntax of 
the statements τν. 175 proposed Standard. Do vp tne 
development of the grammar it was decided in several cases 
to define only a subset of the syntax in the agrammar in 
order to decrease the number of rules., Botn the common and 
data statement syntax enforced hy the grammar allow only one 
namelist. wit oma) commas ον τας 55ο τὸ, type and co 


Statements were also excluced from tne arammar develoned. 


el 





The implicit statement oosed a special croblem which 
was never entirely resolved. The lengtn specification in 
the character implicit statement can be an expression and is 
defined by tne following syntax: 

sympiycit statement» 3:= IMPLICIT CHARACTER 
x X«express)on? ( «letter ranae list»? ) 
The combination of an expression and a left parenthesis 
caused ambiguities in the grammar that ον Eno De 
eliminated. The eventual solution was to .restrict a fhe 


wn ax for the character lengta to an integer constant. 


Re Uotional Statement Desıen 


τευ. τες. or semantic analysis, rary of the 
grammar rules in Aopenacices A and B that define tne FURTRPAN 
Statements could be restructured and της overall FORIPAN 
grammar would still meet tiem crecg)rements of an EAE CI) 
Srammat . These alternate statement definitions miant pe 


useful in semantic coce generation. 


A simple examole of cays is r1llustrateaq by Ente 
following two alternate definitions available for the 


dimension statement: 


DIMENSION «array declarati!|on» 


«dimension stmt» 


«dimension stmt» , 


Sarray aeclaratión> 


«g1mension stmt»? ; <dimen heaa> «array aeclarat|on? 
«gimen head» :?-7- DIMENSION 


ı <dimen head> «array declaration? , 


ee 





The first definition was chosen for use in the final 
grammar because it required fewer rules. The second set of 
rules may be desired for a compiler utilizing the grammar in 
order to determine when the last array declaration 1S being 


DEE EE SS ESO. 


5. -Ἔ ΕΠΕ the bmtamnat 


The orıcoinal LALR(1) arammar was desıaneu to aefine 
the syntax οἵ all the statements in the FURTRAN languaae. 
The initial grammar definition that was aeveloped contained 
Eroximately 350 rules. The taocles aeneratea by, the LALR 
EEupser for tnis Grammar VOOK over Γιαν 179% Merory. 
|hese tables were much too large to be imolementeg in 3 
emer =nosteq como1!er for a loK microcomcuter system with a 
4K ooerating System. Consequently the arammar was sclit 
unto two sections. the first section containea the rules 
for the data and environment definition staterents incluging 
program, subroutiner function, block aata, format, entry» 
Gata, specification and statement function statements. Tne 
second section contained the rules cefinina the format, 


entry, data and executable statements. 


Solitting the grammar in this manner had two 
advantages. The larce table size was reducea to 3800 bytes 
for section ome ana 4200 bytes for section two. 156: SEP 


grammar made it necessary to split the compiler στο 
separate programs for each section; thus different Semantic 


actions associated with identical grammar rules coula oe 
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varied within the seoarate programs. FOR example» a 
reference to an array element could be handlea in a 


different manner in each of the proarams. 


A significant disadvantage of solitting the arammar 
was the difficulty smposed in the desian of a compiler thet 


utilizes the grammar to process more than one program unit. 


jhe two grammars were gesigned so that they could 


easily be combined for use in a compiler that ocerated in an 


environment where memory Size was not as restricted. 


U. GRAMMAR AUGMENTATION 


Ls Overview 


ος ἹἸωτ τα. Grammar Gesign ἱπείυσρα rules aefinina 
He relationsnips arong orooram units, enforcina statement 
order and defining the statements allowea within the proyrem 
στις. These rules were subsequently aroopea primarily to 
reduce the size of the parse tables. In an environment 
where the size of the compiler is not critical tnese rules 


would provide a useful extension to the grammar. 
pP pProgram Units 


The proaram units definea oy the FORTRAN lanauage 
are the main orogram, and the function, Subroutine and block 
data subproarams. A FURTRAN program must nave no more than 


one main program and can have any number of additional 
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subprograms. Further, these proaram units can be in any 
order. fine  LCALR(T) Grammar rules that were developed to 


pmrorce these frelationshics are as follows: 


SImocdgtetams i <proaram unit»? 


<subprogram> 


i1 «subprogram? «program unit» 

Droa am τσ τς «πο Program? 
"τετ οι τ- €subecrocgrom unite» 

<suborogram> ¿322 <subproaram unıt> 

ο ο πο σος <SuUbBoOrosrar unita 

<suproaram unit> i:2 «function suoprogram> 

x subreurfine suberegran? 

u Diockeoara SUBEeFDOFSam> 


mese productions coula oe of value if more than one program 


unit Is to be compılec at the same time. 
5. Statement Uraerina 


Several verstons of an [ο πο) grammar were 
gevelopea to enforce statement ordering within program units 
and the types of statements permittea in each proaram unit. 
An | LALH(1) grammar that met these requirements 15 presented 
mmADppend!x C. The parse tables See for the arammar 


NumAobendix € took aperoximately 2200 bytes of memory. 


These rules could oe :incluaed in a compiler that 
implements the aqrammar Um the memory space reauired 15 


availaole. Am alternative would be to substitute the 
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appropriate semantic actions as is described in tne aesign 


ee the compiler presented later in this paper. 
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En στο ο. Το 


A. OVERVIEW 


The system des1an recommended for implementation of tne 
FORIRAN πούς. οὃπ a microcomputer consists of three 
subsystems: a FORTRAIN compiler that generates a relocatable 
üutenrmediate lanauage moaule for each proaram unit (main 
programe subroutines, Pumctuons» or Block data) puo eje 
FOKIRAN source file, a loader that links the rogules that 
nave been aenerateo nv tne compiler, and an interoreter thot 


executes the intermeatate lancuage. 


The system that ıs described is aesiagned to execute on 
the intel 8080 microcomputer with 160K bytes of memory unger 
the CP/M 5] operatinc system. pn Ms scumcomdgstorecomt"nro! 
oroaram that provices a number οί basic ınput/output 
functions, a console command orocessor, and a comprehensive 
file management packaae for use with a file system. Tne 
file system 1S maintained on diskettes (flocoy disks) which 
contain 256K bytes of storage. This operatina system also 
supports a text editor, a dynamic debucger and the Intel 
8080 assembler. CP/M takes 4K bytes of memory; therefore 
the system desian ciscussed τος ἴπθ implementation οί 
FORIRAN has 12K bytes of memory available. Tne use of LP/M 


or an equivalent system on the BO0ROÓÜ microcomouter directly 





affected the desian requirements and recommendations made 


for the implementation of FORTRAN, 


B. COMPILER 


'' . Orhanizat Lon 


.ΠττΊπ5υ.ΕΠΕ grammar into two sections, as noted 
ermevyious!|yr, had a direct impact on the compiler aesign. Tne 
compiler was originally envisioned as one Program with 
provisions ορ πο  ριο Basses, Tne imolementatian of tne 
spolit FORIKAN grammar required a separate program for each 
mar and a control orogram that provided linkage between 


the two programs. 


To execute tne compiler the user of the svstem would 
moke the control proaram, and pass the name of the source 
file to oe compilea in tne command line as a  Darameter to 
the program. Ihe control proaram would then manage tne 
interfaces necessary between tne pass | and pass có compiler 
proarams required in the compilation process. The final 
outout would be a file containing the intermediate lancuace 


ο ο  οἵςο by the compiler. 


The system is aesigned so that the control program 
resides 1n memory durina the entire compilations The symbol 
table area is left in memory for use by the pass 2 orogcram 
after the oass 1 procram nas comoleted execution. the pass 


el program overlays tne pass 1 proaram when read into memory 





the control program. The memory configuration tor tne 


implementation of this desian is presented in Figure 1. 


COMPILER MEMORY ORGANIZATION 





PEAX 
SAFF 
Set 
El Ed 
Symbol Table 
Pass 1 Proaram 
Pass 2 Program 
ju 


System Information 





Figure 1 
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[his section discusses the FUNCIONS? the  gesign 
requirements ano recommendations for tne control! prooroam, 
the pass 1 and pass 2 proarams, and the interfaces reauiíired 
among them necessary to imolement the FURTAN como1ler baseoc 


ου πο LALR(]) FORTRAN Grammar. 


E Control Proaram 


[ne σι Buürsose of ος Control orogram pe. Gto 
contro! the overall comentario Y process. τω SE 
aos a tnis it must perform two basic functions: (1) tne 
loaaing of the pass ἱ οσο Cass (e p»proorams. (aba fna 
Mia l1zatrion of their execution: and (g) the maintenance 
of common information such as compiler togales ana symhol 
taole necessary to both oasses. Ihis reauires thart tne 
eentrol proaran renain in memory auring the entire 


compilation.s 


The bulk of the executanle code for the control 
program resides 1n memory just below the CF/M operatina 
estem (see meure I. Upon initiation of the proorsm bv 
the user, execution beains at 100 hex (106H) and 9η 
immediate jump is performed to the first executable byte of 


code located in the ucper part of memory. 


The first task tne control program must perform 1S 
to decide whether it is being invoked from either the pass | 
MD ass Te Ppeocram ος at the initiation of the FURTRAN 


compiler. The appropriate actions can then be provided 
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Based on this decision. A control flag which can be altered 
by the pass l and pass ὁ programs can be used to implement 


this reauirement. 


“hen the control proaram is executed for tne 
ExutOos!ization of a compilation it should perform the 
moltowing functions: (1) ο ο σος its “scratch pao”. afea 
for use by the oass 1 and pass d programs, (e) save tne 
mue control block for the FORTRAN source file and open tne 
ορ inout, (5) maintain the file control bloc* for tne 
intermediate larguace file and open it τος. outputs (+) 
initialize the syrool table area, (5) reag the executable 
Mewes 1116 for the nass | oroaram into mevory becinnina gt 
100n, ana (o) πο το το transfer control to the pass 


1 ΟΓοάρόπ. 


“hen Γης SON Ena proaram 1S σ ιοκος at tne 
5 οιἱοπ of the pass I program it should cneck for a fatal 
,..τ io the pass | phase of compilation which would 
terminate execution. ο δρα ο ουσ the COM frie for the 
pass d program can be read into memory anc control 


transfered to 100H to begin execution of tne oass ὁ eprocram, 


When tne control orogram is executed via a transfer 
from the pass οὁ program it should again check for a fatal 
error in the Dass 2 phase of compilation ara terminate 
execution if necessary. It must also determine 1f another 
program US to oe combi led: Ef an additional ορο ποπ 


unit is to be comoilea the control program must reinitialize 
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the symbol table and "scratch pad" area, with the exception 
unmconpiler toggles,; and reloao sand transfer control back to 
mare pass | orogram to9 continue the compilation process. Et 
no more program units are present on the source filer, the 
control program must close the FORTRAN source file ana tne 
ExUcsmedirote lancuage file and return control! to the CP/M 


operating system. 


Maintenance cf the filen Control blocks “ry tne 
wontro!i program for both the FORTRAN source file -ang 
E mediate language file is critical to the system. 


Pointers must ve maintained Bor Boch files Im order το 
determine the correct record to oF orocessen to oput Or 


Scout « 


[he Ecoroten οσα area located 1n bres ron tro. 
proaram vs avaılable for use by both tne cass 1 anu pass e 
programs. Information maintained in this area can incluce 


compiler togales, error flags, and any other interface 


information required hy the pass 1 and pass c proorams. 
ó. Pass ! Program 


The pass 1 program implements the grammar presented 
DG Appendix A. This proaram processes the ΕυΠΙΡΑΝ 
Seorements up to (out not including) the first executable 
statement. Routines for syntactic and semantic analvsis, 
symbol table manioulation, and a oarser must be included in 


the program. This section discusses the design requirerents 
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κι. 


imposed by the FURIRAN arammar and some additional design 
@ensicerations necessary for implementation of the proaram. 
The parser and scanner  descrioed in this section were 


implemented and testec. 


ar Parser 


The parser that was adopteu for suse with tne 


pass t orogram is based on the coarse action generation 


algorithms used to analyze LALK(1) arammars. 


a 


The parser controls the execution of tne pass 
Sroaram. It receives a series of tokens from the scanner 
amd analyzes tnem to cetermine 1f t^ey form a valic sentence 
IE the FORTHAN grammar. It bases tnis geciS!on on the next 
Mout token anu information previously accumulated on 8 


parse stack where the parser states are maintained. 


The basic actions performed pv the parser 
include a shift action tnat reads a new token ang pustes fre 
previous state onto the stack», a reduce state that pops tne 
number of elements equal to the handle of the procuction and 
puts a new state on the stack, an accept state that 
ter tere the input Conforms to tha grammar, ang an error 
state that ingicates when a syntax error has occured. 
Additional Stacks can be usea $n parallel with the parse 
Stack that relate to the translation of the proaram, such as 
pointers into the symbol table and temporary values used τη 


y 


reductions. 
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In order to stoo the execution of the pass | 
program the grammar allows the parser to proceea until it 
has analyzed an end statement, when no executable statements 
are found in the rrogram unit, unt1l it nas analyzed tne 
reserved word in the first executable statement, sucn as VO 
or READ, or until an assianment statement 1s recognized. im 
the case of the assignment statement, where no reservec word 
N-ucontained im the statement (e.q., A - 3), it parses up to 
the equal sian. Tne information previously scanned for tne 
executable staterent must be saved for hee ον πο αρ. 
Sroaram to oroviae initialization of tne scarner and to 
HON for any semantic actions trat reec to be perrormeug. 
Dr antajnina a stack tnat always contains the Foot three 
tokens processed, AaS Normat ioù Gan then ορ Provrueo to 
the pass e program via tne "scratch pac" in tie Beart ro 


programe 
D. Scanner 


Ihe function of the scanner 135 to "proviee tne 
tokens defineg in tne FORTRAN grammar to the parser. These 


tokens include reserved words, soecial Characters, tne 


exponentiation and concatenation operators» statement 
labels, identifiers, array identifiers, "format ποστ ος 
"end-of-statements", and integer, real, character, and 
mouble precision EGnstants. The Scanner that was 


implemented in the pass 1 program encountered no special 


problems in recognizing these tokens with the exception of 
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identifiers, array identifiers and the "end-of-statement" 


token. 

Kderteitserssangdborray ıgentitiers both have thre 
Same structure. They are a sequence of one to six letters 
EXE digits that begin with a letter. In oruer το 


differentiate between them, it was necessary to include 
bester ton with the semantics necessary for processing 
dimension statements. hen the reserves word DIVMENSIUN was 
encounterec a flaa was set to indicate that a token of this 
horm followed by a left parentnesis «as an array icentifier, 
This nudae was checked bv the scanner following the initial 
test EC reserved words. Ley tre flag was not set, ftne 
svmbol was looked up in the symbol table to aetermine τί it 
was an  arravw identifier detined ın a previous dimension 
statement. if these tests failea, the token was assumed to 
be an ıdentifer. The use of this tecnnıaue imoosen the 
requirement tnat arrays could not be referenceg in any 
FORIRAN statement prior to their declaration in a dimension 


Statement. 


The recognition of the end of a FUR FRAN 
statement hy the LALR(1) grammar implementation recuireo an 
"end-of-statement" tcken transparent to the user. A 
lookahead feature was used in the scanner to nelo determine 
whetner the nex line was a continuation of πο οσο του 5 
statement. Since normal FORTRAN card conventions were 


maintained, the decision could he basea on a line SOs itr om 





Soimter that maimtaineg the “card column” oosition of the 
current Symool heinc considered by the scanner. “hen 8 
carriage return and linefeed were encountered, the position 
of the next nonolank character was determinea. If tne 
position was not "cara column" six, an  "end-of-statement" 
token was passed to the parser. The line position pointer 
was also used to recognize the end of valia statement moot 


pre Gord « column” seventy-two. 
Cu semantic Analysis 


ἃς noted creviscusly, the arammar for the cass i 
progrom does pu enforce the orger ang t^e tyces ou 
NE ments allowed in each program unit. Urger car ca 
enforced mn the semantics of the orogram by the use of tar 
flaas: one flag to determine the tyoe of program unit beina 
processed (main procram, suoroutine; fume tono cup πες 
data), anda second flaa to aetermine τέ a particular 
Statement is valid based on the previous statements that 
have been processed. Each statement in the grammar for this 
program has an associated reserved word. ynenever 8 
reserved word for the statement currently being processed 15 
encountered, the flags can be checked to determine if the 
statement order is correct and if that type of statement 15 


mero τη the orogram unit. 


The use of the "format input" token in tne 
grammar  reauires the processina of format statements If tne 


semantics of the program. Ine adgit!on; USA tor mat ion 
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must be saved for later use by the pass 2 Program in the 
processing of the executable statements. This can ve 
Eccomolished by either writing the information required to a 
floppy gisk file, or by saving tne information- in tha 
"scratch pad" area of the control program. since the number 
of format statements may be large, the exact implementation 
.,  υε Dased on the actual memory available for use in the 


eontrol prooram. 


[he general expression definition in the FURTRAN 
πότ has a direct impact con tne pass 1 erSsgram., “ine 
Acs must entorce the tyme of expression (character; 
logical, Of ese iitnmenrtic) allowed withir each statement οὐ 
Me FORTRAN input. In some cases, such as  dirension 
statements, only inteaer constant expressions are valig. 
Integer constant expressions are a special case of the 
arithmetic expression in weyen only integer constants. or 
variables of tyne integer are allowed. The semantics of tna 
compiler must also process these special expressions and 


provide for their evaluation and use. 


da Code Generation 


The type of code aqeneration produced by a 
compiler 15 niohly aependent on the system in which it 15 
implemented. The design decision to produce an intermediate 
lanauage instead of executable machine code was based on two 
major considerations. Firsty the oroguct!on Ont an 


intermediate lanauage enhances the transoortaoility of an 
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eventual System implementation οί FORTRAN to other 
microcomputers Snot ουσ στι Ευ Η. oecond, the existence of 
Bua interpreter of Basics [5], which translates an 
intermediate language output from tne Basic-E compiler, has 
already been successfully implemented in the comouter 
laboratory at the Naval Hostaraduste "school. This 
interpreter is an excellent candidate for modification for 
use with FURTRAN if tne 3ntermejiate lanauage orogaducec oy 
the FURTRAN compiler 15 comoatiole with the LOS Tae 


intermediate languaae. 
a Pass e@ Program 


The pass d crogram imnlements the grammar oresented 
En Appendix tb. Tnis proaram processes FORTRAN executable 
Statements. Syntactic and semantic analysis, symbol table 
manipulation, and parser routines must again be includec in 
the program. This section describes the des|an requirements 
imposed by the FORTRAN grammar and adaitional uesıan 


considerations necessary for imolementation of the program. 
a. Parser 


ο ο iaa cha! controls the execution of the 
ἔπ c pnogram,. con be identical to the parser descrived τη 


the previous section. 


σου οπου. τος ρογςσοϱς "s terminated after pros 
end statement ES parsed. RIQthys Pont the proaram must 


determine if there are Jod clon a | Drodram units το. ος 
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C@@MPilec. Mica ος "ουσ Cy CcRecking to see if  amytnh 
EDT πο ὃ soft end-of-file (13n) or a RKarc end-of-f 
E urs after tne carriade return and linefeeo fcllowing 

ena statement. The eporopriate flac snoutc then De set 


the "scratch oac ames ofthe comtral ocoer3 amd - ckecut 


Mis terres to thie control ordcran. 


b. Scanner 


[Memsceceenesesicnes J fer use in une Mess 
Eram can De δν similar re the scanner iff} the cas 
oor any. IE was wen" e ker is ΠΕΡ οηιν αποζτις 
tocan bet ust te Beer: zes Ἐν Me 73555 iz sc ac 
Mec | emehit ation. 

ine οι νι ρα δὲ ίσα Net ween i Bete tee i ores 
array i1d0entifiers DS D Vencee  reculpyec in the Soman 
analysis. mw τος σοι alt arravs have been cecianec 
Ane. array icentifiers are Contaimea 1n the Sveno! wt afi e 
ου ο ess1ly recocahnized. 

"t the initialization oF the scanmer, tre tok 


caman Cer tne ἘΠ 


previously parsed Ke tne Cass 1 = 


ay 


executable statement rust De recoverea from tne  "scre 
pad". Cae] on s@rovicingcwymese tokens for analysis anc 
EUMe scenner sist. Oe imclussa in the proaram orior 


Erolninco any new tokens for the First axecutacle 


ul 
-4 
(i 
et 
(D 
I 
(P 


$9 


na 


1 


n 


Uu) 


a) 


¿Y 
3 


] 


O 


0) 


(D 


ο 


(Ὶ 


ry 


(p 


MN 


A 


ο 


OY 


u 


un 


σι 





Cis Semantic Analysis 


ASNO Red Creviously, the format specificatton in 
the format statement must oe handled in the semantics of tne 
Programe Ion addition, Drovision must be made for retrievina 
the information that was produced for any format statements 


that were processed oy the pass ἱ proaram. 


The arammar tor Gass d )mposes sdscitıon.al 


reauirements for expression evaluation not necessary in tna 


pass l BrOogram, For example, one torm Tof t^e Bart 
Statement wnich 15 acceptable t^ the arammar τον πη 
<exoress1on>. Tne expression may either Be wn inteaer 


constant aesignating 3 statement label, ορ a character 
expression. Thus, tne serantics must allow the Statement 
lave! ο ος οὗ ο as it is parsed uo tThrouah the expression 
nemnition associated with a print statement. Sj cer 
requirements exist for the read statement ano complex 


Sons tanmt definitions. 


Ge Coae Generation 


Since the pass e program performs code 
generation for all FORTRAN executable statements, the 
proaram may exceed the memory sıze available. I this 


Beceurs, Consideration snoula be qiven to either restrictina 
the tvpes of statements allowed for use in the FURIRAN 
Imellementstien or to oroduc!na parse actions in pass e and 


adding a oass $ proaram to orocess these parse actions. Tne 
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additional orogram cculd then aenerate the intermediate 
language basea on the parse actions, associated information 


mni available symbol tahle information. 


Ee EES Ee process tne 
intermediate Janauage modules aeneraten by the compiler for 
the ους Proaham Umvts;, anc to produce a zera-acaress 
ν.' ποις lanquace module that can be executed ty the 


interpreter, 


The following tvoes of information asscciateo with each 
Ensepmedviote languace mocule are necessary for loader 
implementation? (1) t^e name of t^e current mocule, (2) a 
list of external names ano references witn detinitions of 
their use, (5) the adoress of the first byte in tne coge 
area of the current module, ana (4) the length of the coce 
area of the module in oytes. Dutout from the loader should 
be designed to enable further linkage t all external 


references have not yet ceen resolved. 


The actua! implementation of a loader was not considered 
part Of this thesis project ana Is τοις for future 


Consideration. 
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Oe INTERPRETER 


The function of the interpreter 18 to execute the zero- 
adaress intermediate language prouuced by ertner tne 
compiler or the loader. τη: .οθο1πτ, a la external 
references must te resolved in order for the intermediate 


language module to be interoreted. 


. Ihe desian of an interpreter is dependent on the 
Specific machine on wnich the FORTRAN language 1s to ce 
implemented. The run-time monitor used fer- erecting tne 
Intermeciate language pomsduced by the tasic-=E compiler [9] 
is an example of an interoreter trat has been SUCCES Uy 
implemented on rhe, CeO Under the L?/Y operetna system. 
The monitor provides a number of features that would oe 
moet! in the »vnteroretation of FORTKÀN such as the use of a 
NECSUUIna pont package {1} to perform arithmetic, τι ποστ om 
evaluation ande CONVEFSTON operations on Sc pit- floating 
point numbers. lf tne intermediate language generated by 
the FORTRAN compiler is designed to be compativle with the 
lanauage producea bv the Besic-E compiler, tne modification 


of this interoreter to acceot FORTPAN would creat|v 


facilitate the imolementation of FORTRAN on the 8080, 
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DV se ONCLUSIONS 


The successful completion of the formal FORTRAN . arammar 
demonstrates the teasibDility of defining an ambiauous 
language, Such SANFOR PAN, using an LALR(1) grammar. 
Mmorguities in tne grammar can be resolved by providina a 
broader definition for the language ana compensatina 


Semantic actions by a comciler th3t implements the arammar. 


The FORTRAN grammar whicn was developeag was structured 
to define tre largest ον Ἱσ ορια οἳ προ σος arain 
proposed American National Standara FORTRAN. However, ΕΠ; 
Should not orevent a user of this grammar trom redefining it 


mameet the requirements for imolementation on a σοι or 


machine. 
The use of a formal language ana automatic parser 
generation methoas proved extremely valuable mn tne 


Eusrructionm of the FORTRAN comoiler. The parser that was 
available for use in processing the parse tables, «hen 
combined with syntactic and semantic analyzer routines, led 
to a modular design and the systematic construction of a 


Bmovler rather than an ad hoc tecnniaue. 


', νυ’ 51τΕ;.,τΕ5 πὶ “ΠΕΠ. πάς. oresented to Support tne 
FORIRAN lanauage on a microcomputer system witn lón bytes of 


memory is feasible. However, the lack cf memory Space 
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remains a problem. It 18 recommended that consiageration oe 
given to the replacement at those rules, especially 
input/output statements», which coulo be tailored το tne 


wee fiC machine on which the comoiler is implermentea. 


It is hoped that the LALR(1) FORTKAN | arammar and tne 
Beceosmpanyina system oesian recommendations will establish a 
basis for the implementation of FORTRAN on 8 microcomouter 


Syotem. 
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APPENDIX A - FORIRAN GRAMMAR SECTIOUN ONE 


«program» 


«program body»? 


Eeer ment A . 


<prog stmt» «program body? «end state» 

«prog stmt» «end state»? 

«program body» «end state» 

«end state» 

«subr stmt?» «program body» «end state? 

ΠΤ ΟΠΕ» «επα 518662 

«func stmt» <orogram body» «eng sta*e» 

«*unc stmt» «end state»? 

«block cata stmt» «orogra"» body?» «enc state» 
..= <startement?> 

ı <orogram body?» «statement» 

- «label» «oarm stmt» «eos» 


«label» «1mol stmt» «eos» 


ı «label» «dimen stmt» «eos» 

y «label» «common stmt» «eos» 

| «label?» «equi|v stmt» «eos» 
«label» <type stmt»? «eos»? 
«198062 «external! stmt» «eos» 

(1 «label? «intrinsic stmt» «eos» 

| «label? «save stmt»? «eos» 

( «label» «data stmt»? «eos» 


abel? sStmt fume stmt> <eos> 


45 





«enda state» 


«exec stmt 


«eng stmt» 


SO TOS Stmt > 


Pec Vabpeleom<entry stmt= <eos> 
| «stmt lapei» <format stmt> <eos> 
>= <label> <exec stmt reserveu word> 
| «label?» «identifier? = 
| <lanel> «array element» = 
| «label» «substrina name» = 


"IN οσο Simi? 


reserved word» ::- DO 


φ 
e 


bat 

ı ASSIGN 

ı GU 

μα le 

sie? 

T PAUSE 

i CALL 

|| READ 

ı WRITE 

ı PRINT 

WERDEN 

CLOSE 

| INQUIRE 

λος ACE 

ΠΕΙΤΕ 

ı RERIND 

ΕΙΠΕ 
>= END 


«5 «label» PROGRAM <igentifier> <ecs> 





Huoct data stmt» ::s «label» BLOCK DATA «eos» 
1 <label> BLOCK DATA <identifier> «eos» 
<subr stmt> ::Ξ <label> SUSROUTINE <identifier> <eos> 
' «laoei» SURHOUTINE «arg l:st^? «eos»? 
ο stmt» :t- «label» «func 1d> 
+ «label? number type?» «func 12a? 


| «label?» «char tyoe» «func 1a» 


mco id» ::- FUNCTIGN <identifier> «eos» 

e FUNCTION «1gentif ier?» ( ) «eos»? 

|. FUNCTION «ara list? <eos> 
ESI stnt» ;:= PARAMETER <igentifier> = «constant» 

ο ος πιο +» €pydentifier^» =. <corstant> 
nei stmt> ::= IMPLICIT <imnp! tist> 
πο sumpt», emo! lrst? 
<imo! list» ::- <ımol list heag?» «letter range» ) 
<imol list head?» ::= «number tyoe> ( 
ΑΚ ΤΕΕ { 


ο ολες *x*o«*itecer constant» { 


ı <ımol list head> «letter range» , 


«letter ranae»? : <identifier> 


v «identifier?» - «1dentif ier» 
<dımen stmt> ::= DIMENSION «array decl» 
«dimen stmt? , «array decl» 


«common stmt» ::= COMMON «common name?» «common nlist item» 


+ Common stmt? , «common nlist item» 
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«common name? ¿<= <empty> 
I <label common name> 
ı <double slash> 
<common nlist item> :?:=2 <igentifier> 
array Yd» 
1 «array aecl> 
«label common name> 33:= / <identifier> / 


Seri v stmt» ::- EHUIVALENCE «eauiv nlist» 


«equiv stmt? , «eauiv nlist? 


τιν nlist» ¿22 <equiv nlıst head> <entuiv nlist item» ) 
<equiv nl1ist heag> ::Ξ ( <eauiv nlist aotem»? , 
ο οσοι vonlıst "esa> 


<equiv nl1st item»? y 


«equiv niist item> „= <jgentitier> 
ı <array 1d»? 
ı <array element» 
ı <substrina name» 
<type stmt> <<= <nurpoer type stmt» 
ο ορος ο E DE 

«number type stmt» ?;- «number type? «tvpe 1tem> 

| «number type stmt? , X«tvpe item» 
«type item» ;::- «identifier» 


ı <array 1d» 


 xarray dec!» 


«char type stmt» ::7 «char type» «char name> 


( «char type stmt» , «char name» 


I 





«char name»? 


«external 


. 
9 


stmt? .: 


= <iden 


ı <ıdent 
ı <array 
ı <array 
κος ὃν 


ı <array 


Ξε 


«e 


EE Urinsic stmt> :;- 


«Save 


«Save 


«save 


«data 


«data 


«data 


«data 


strr> 


ist > 


item? 


τσ πι.” 


list? 


head? 


nlist 


LOSS 


SAVE 


1 “Save 


SE 


<save 


ASI OA 


<array 


<130e] 


<data 


«data 


ISS ta 
o O 
SER 


tem> ::5 


Men 
ifier> € echar lem» 

gacı> 

decl> x «char len» 

id? 

10> * «char len»? 
XTERNAL «identifier? 
xternal stmt? , «identifier? 
Vir Ee Bee CR, 


τεγργΊο-ις 5Εεπι7 er EE EE 


E, 
<save item» 

list> , <save 1ten> 
tifier> 

yd? 

Common name» 

ir st2ssedaOta ciwsto temo 7 
head» «data nlist tem» / 


list? <dəata ClisSst item? v 


heaa> «data nlist item» , 
«identifier»? 

«array id» 

«array element» 
<suostring name> 


<imolied do list> 
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BRoStowci!ust item» :t:- <loentifier> 

ı <constant?> 

ı <integer constant> * <constant> 

ı <integer constant> * <identifier> 
ο <cident ifie? + <cconstant> 
ı <ıdentifier> x <iaentifier> 

«implied do list» :?7z ( «array element> , <do list» ) 
ου πρ ved πο list? z «do Iıst>-) 


mrmetrumMe stmt» t: «ara list? =Z <exp> 


<ıcentifier> ( ) * «exo» 
«entry Stmt» :i- ENTRY «identifier? 

ora list» 

Pees ye<icentifaer> ( ) 
«format stmt» ::= FORMAT <forrat inout» 
Salome) 1St> :23= <identifier> = <exp> e <exp> 
ı <ıdentifier> ZZ «exo» , «exo? , «exp»? 
Enc ref» ::* «identiíifier» ( ) 


σου σε 


«arg list? : «arg head» ) 


<identifier> ( «ara element» 


«arg heag> : 


1 «arg heaa? , «arg element» 


«arg element»? 


^ 
Ou 
3 
7 
Qj 

κκ 

Q 
V 


Erroay deci! 37 «array 1d» «dimen decl list?» «di1men decl ) 


<dimen decl list» ::- ( 


i1 «dimen decl list» «gi1men decl» , 
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<dımen decl?» :;i- «exp» 
len ns «exp» 
Errav element» ::= «array element 


|i 


o 
^t 
V 
95 
Η 


<aray element <array 


Eeubstring name» 3 


; «array element» 


«exp» : 


«substring decl» : 


| repo i ) 


yo. T 


| «array element 


«exo» ) 


Iıst> «exp» ) 


list? «exor» , 


= <identifier> ( <substring decl> 


( «substrina dec!» 


(ONU Sexpsc) 

iu: c 
Sexmp» ::- <loarcal term> 

"cep keck term» 
E ogUcal term» ::- <logical factor> 
moore tern? AND. «logical factor> 

au cucal factor?» ?*:- «logical primary» 

pa au ο οσο ισα] primes.» 
E odNcal primary» ::= «Xcnar exp»? 


| «char exo» «rel 


«char exp?» !:= Xarith exp»? 
NE 
«arith exp» ::= <arith term» 
ı + <arith term> 
ı = <arıith term> 
' 


v Saritn exo? 


ı <arıth exp> - 


T 


op» «char expo» 


ο ὅπου χο «double slash> <arith exp» 


+ <arith term» 


<arith term? 





Sach terme ες <arith factor> 
ο ου ο ara Sari th factor? 


(  <arith term> = <arith factor 


mam tactor> τες <arith primary? 


ο οπου aC or? —<exDOM op^ «arith primary? 
geh primary» ti- «constant» 
| «identifier» 
|» «array element»? 
ı <substrinag name»? 
ες refte 


» Sparen exp? 


5η exo» Σε ( <exc> } 


ona tant> SS <jnteger constant > 

|! «real constant»? 

me dgolerlore Constant > 

1 «loa!cal constant»? 

Ge -emat “COs © ant > 

ı <corplex constant> 

ποιο constant> ::2 ( <real constant> „ <real constant> ) 


moo» ::- .LT. 


„er, 


aa e 


δω 
GC «ΝΕ. 
τ 
ΘΕ. 


= .IRUE. 


aai Cal constant> : 


FALSE. 


Se 








«numper type» 3:32 INTEGER 


οι E πας δη 
E OMPI 
eos LC ANG 
<char type> ::= CHARACTER 
' CHARACTER x <char len» 
ορ len> εξ <parén exp> 
: “integer constant> 
AUTAT) 
«label» :i- <emoty> 


ius stmt tobe i> 
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APPENDIX B = FORTRAN GRAMMAR SECTION TwO 


Greet pt :2= <orogram body> <end stmt> 
«program body» :1Ξ «statement» 
, «program body?» «statement»? 
«statement? ;:- «label? «data stmt» «eos» 
ρος. οτι στπῖρ 
(| <)anel> «do stmt? «eos»? 
| «*laoel» «entry stmt? «eos» 
au coc «fonat stmt» «eos» 
| «logif exec stmt» 
<logif exec stmt» ;:- «label?» «assign stmt? «eos»? 
pasiobpel»sooto stmt» «eos» 
; <lanel> <aritnif stmt> <eos> 
ΙΓ «label» «continue stmt? «eos» 
| «laoel? «stoo stmt? «eos» 
|! «label? «pause stmt? «eos» 
ı <lavel> «call stmt» «eos» 
+ «label» «return stmt» «eos»? 
(| <label> «read write orint stmt? «eos»? 
(| «laocel?» «open close inauire stmt? «eos» 
1 «label» «bpacksoace enufile rewind stmt> 
«eos» 
«end stmt» ε55ξ END 


ES υπ data τοι «data clist item> / 
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«data list> ::= «data nead» «data nlist item» / 
|! «gata list» «data clist item» , 
eaata head> ::= DATA 
|! «data heaa?» «data nlist item»? , 
«data nlist item» ;:- «identifier» 
(| «array id» 
ı <array element> 


i <substring name> 


<implieg co list? 


^ 


= <iJjentifier> 


esta clıst ıtem> : 


«constant» 


mel CeCe rr css tanta * «constant? 


ener consteni> x <iogentitier> 


οπλο ρου «constant» 


«οσοι er> a «jocenta1f1Pr» 


amoled do list» ::- ( «array element» , «go list» ) 
UR ORC nove ου mm εὐθ. 11515) 


use stmt» ::= PAUSE 


- 


PAUSE, <imteqcer constant> 


PAUSE <Cnareconstant- 


STOP 


<stop T 5η 
(|. STOP «intecer constant»? 
«ει cons Cant > 
Econtinue stmt?» ::- CONTINUF 
EMueturm stmt» 2:3= nETURN 

(| RETURN «exp» 


ορ οι ο πο ses thr <paren exo» <a1if slaoel!s» 





τ. οΙσδυςσ <:= <tnteaqaer constant> , <integer constant> , 
«inteaer constant» 
“gait Stmt> 222 ΙΓ «paren exp» «log|f exec stmt» 


- ASSIGN «integer constant?» [IO «ident itier» 


«assian stmt» ; 
| «identifier?» - «exp» 
| «array element?» - «exp» 
ı <substring name> = «exp» 
mo Stnt? ::- DU <sınteger constant> <do list» 
Ero stmt» ::- GO TO <inteaer constant> 
ο ο ο στι Masel !vst» ) «exp» 


ı 60 HIO <1dentifier> 


Eure er σος <stat Spell’ του J 


Estmt japel list» ::- ( <tnteaer constant> 
aber Trst? „ <ıateger constant» 

Esa stmt» ::- CALL <identifier> 

ο αλ) σου Sto 
Semtry stmt» ::- ENTRY «1dentifier^? 

| CNTRY «ara list» 

ter εἰ οι τέλους €( ) 
Eormat stmt» ::- FORMAT «format inout» 
<open close ınquire Stmt> ::= <open close inquire ΠΘΘΩΣ 

<exp> ) 


ı <open close ınauire heac> 


«io spec> ) 


open close inquire nead> ::z OPEN ( 
πο « 
ΠΠΠΠΙΚΕ ( 
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i| «open close innuire heau> 
«exp» y» 
|: open Close inauire head» 
S10 Spec» , 
ELckspoace endfile rewing stmt» <23= BACKSPACE «ber list? 
metric “oer 11st > 
+ REWIND <ber list> 
Seer Jist> 1:7 <exp> 
ο σον κιτς spec» -) 
AOS Eee? y Sexp> J 
1.16 Print stat> ες «reag print stmt» 
m<res3o write ci l1st> 
pead write το 1st» 
Eread print stmt> ::= KEAD «exo» 


READ <Spray 10> 


READ * 

I PRINT <exp> 

του EE 

ΠΠ. 

πα  οσ ου οὓς δισ <io list item? 


- «nread write c1 list? «10 list item» 


EuESSg write 1o list? : 
ı «read write jo list? , 
πσ σοι tem» 
ΤΕΙ list? i=: «read write head» «ci list item» ) 
«reag write nead» ::= «read paren»? 
evi Lat Ee 


; <read write heag> <ci list tem^ , 
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Ser, list item? ES «exp» 
ťi SIO Spec? 


<array ig> 


«array block item» 2:32 «array element? : «array element» 
y <arrav element» : 

1 3 array element» 
AO implied do list> ::- «complex head» «do list»? |) 

Ec ο. ο "ο nead>.<co l16t> y 

<io do list neaad» ::- «complex heaa> <exr> , 

ı ( <arrayv id» , 

(pd Sacreay oloc« Tfteaem^ , 

EON ο πο Ted Go. 11st > oy 
AES cogo Sr Reasi «10 13st 0696752 
Eo i1st item» 1:7 <exp> 
» “array 1Ωα» 
| «array block item» 

IUS ο πο το ο list? 

«10 spec»? ::= UNIT = <exp> 


ı ERR 7 «integer constant» 


REC = <exp> 


y END 


<integer constant> 
ı FMT = <array id> 

1 FMT = <exp> 

EAT mx 

|. FILE 7 «exo» 


STATUS 2 <axd> 


Sö 





ı BLANK 
|» ACCESS 


pee wey 


σε 
ı MAXREC 


X lo 


OPENED 
I NUMBER 
' NAMED 


y NAVE 


E 


Sien 


carent 


pets Ξ «136 


ους 


<a FO 


«arg list? «arg 


<ide 


«ara head? 


«ara 


=> < 


> i1 


«arg element 


eS 


t 
i κ 


«array element» 


Saray element jist 


<substrina name> 


> 


<exp> 


«exo» 


«exp 


«exp» 


«exo» 


«expo» 


i 


«exo» 


«exo» 


«exo» 
«exo» 


C «exo» 


= <exo> , «exp» 


tıfıer> 


if1er» - «exp» , «exp?» , <exp> 


5 


ntifier> 
ασε 


nead> ) 


ntifier> ( <arco element > 


head» , «arg element» 


exc? 


rray 1d» 


«1nteger constant» 


«array element list?» «exp» 


$= «array id^ ( 


i list? «exo» 


«array element , 


Ξ «identifier» ( «substring decli» 


«array element» ( «supstring decl!» 
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ο συιρπα decl> **- «exp» : «exp» ) 


SO) 


> - 
98 
ΝΕ 


Sep» :t:- <loajcal term> 
jg «exp 0R. <loaical term» 
z:uooscal term» *:- «logical factor»? 


asc cscaUtecrm» AND. <logical factor» 


Z <ļlogical primary? 


«loascal factor? 
EENEG marv? 


. 


Eiere prımarv> ::>2 <char exp> 
ern > ο op? Schar exo» 
Senor exo» :3:= <arıth exp? 


(íscnar exo» «goub]le slash» «aritn exo» 


τη exp» :*2 €«5»3rith term» 


+ <agrith term» 


=< th term > 


-— ae 


<aritn exp> + <aritn term> 


<arıth exp? - <arith term> 


<grith factor> 


supthn term» $ 
MANO tera» /7—«arijitn factor» 


| «*«arith term» * «arith factor» 


<arıtn primary? 


<arith factor» 
m sarrthotactor» «expon ob» <arith primary? 


>= «constant» 


Sarith primary» 
ı <icentifier> 


<array elerent> 


ου 





! <substring name> 
ο. τς οὐ» 
| “paren exp> 
&Baren exp» i?- ( «exc» ) 
«Constant? :i7 <integer constant»? 
» «real constant» 
(| «dble pre constant» 
ο οσο Constant > 
(me chasnoconscant» 
« complex constant» 
Ecompolex constant» ::- «complex head? <exo> ) 
poomplex head» ::- ( «exo» , 
οἱ ορ» σεξ ΕΤ. 

|. ος, 

DRE. 

LOS NES 

esie h 

(GE. 
Eu ucal constant» :;:- .IRUE. 

PAIS Es 

<label> 3:= <empty> 


1 «stmt label» 


Al 





APPENDIX C = FORTRAN GRAMMAR FOR STATEMENT ORDER 


Serogram> ε5:5 <orogram unit> 


ı <subprogran? 


y <suborogram> «program unit»? 
ο οοροἩυι υπ. ἵδ τε <maın orogram> 


ο ο τος unito «suborocoram unit» 


«subbrogram? :: SscobPIPoOdgmran UNIT? 

δι ορος ο <sübDPprogarsm unit» 
ο τος η UNIT? 3:;2= <funcetion suoorogram» 
<suoroutine surproaram> 


ES Toc cata suboroOaram> 


soroa stimt? <maın program bocy> 


<main program> : 
ı <main procram body> 
EuDrogtine subprogram» ::> <suhr Strt> <sub program body» 
ı <subr Stnt> <main program bocy> 
; <suor stmt> <block data hody> 
|! <Subr stmt> «end stmt» 
EmUunction suborogram» ::- «func stmt» «sub program body» 
ESTU ena lo program body» 
iae Unc ens <olock data body> 
pectUGeEnStet> <end Stat? 
<block data subprogram> ::- «block data stmt» 


<block aata οουν» 


ο k Jata stmt> <end stmt > 





«main program oody? ::* «main exec? «end stmt» 


<subprogram bouy> 3:32 <mainl imol? «eng stmt» 


! €«maingd soec» «end stmt»? 
|! «main $ func» «end stmt» 


"DL supiEmpi- send stmt» 


ο ο σος εσοοο tmt» 


Ἱ τσουος func» «end stmt» 


|! *subü exec» «eng stmt» 


ΞΡ retura> <end stmt> 


OE data Dody> ¿2 <blokl pelz «end stmt» 


| <blok2e soec> «end stmt? 
, eG toOkS Gata? senna st 7t> 
ο. οκ) πο» ::= «imp! stmt» 
ρου stmt > 
«νοκ ποι» ειπε] stmt > 
ΠΕΙ πο «parm stmt» 
Smoke SDeC> ::= <spec stmt> 
ΟΡ: ἵπε|7 --οεε stmt» 
y <blokdé spec> <spec stmt» 
|! «blok2 spec? <parm stmt? 
sodok5 data» ::= <data stmt> 
ı <bloki impl> <data stmt> 
ı <bloke spec? «data stmt»? 
| «blo«35 data?» «data stmt»? 
Span :mpl» ::- «format stmt? 
ο ο οκ Imei. <format stmt> 
i «emavml mo > «mp! stmt» 


e 





mein tmol> <oarm stmt» 
ı <maınl imol» «format stmt» 
<maine spec?» εε.εΞ- «other spec stmt» 


| “<pblloki imol> <other soec stmt> 


= = 


<bloxé spec»? «ο ος "σος T Stmt» 
ı <blok2 spec» «format stmt» 
σι ο πο «other spec stmt» 
ı <mainl imol> <spec stmt» 
(| <maine spec? «other spec stmt» 
| maine spec? «spec stmt»? 
( <maine spec?» <parm stmt? 
παπα Seec> <tormat stmt? 
Ea0m5 func» ::= <stmtfunc stmt> 

a πο -sstmt func stmt» 
[eno OKC wSDeCc> <stmtfunc stmt» 
ο ιο data? <stmttunme stmt» 
mecOlonSecata> <format stmt» 
PecmMalninimo12> <Stmtiunc stmt> 
Imain] Tmol? «gata stmt» 
| «mainc spec» «stmtfunc stmt» 
ı «maine spec?» <aata strt> 
ποια» πο «stmt func stmt» 
πο πο που -αδις Stmt > 
ο ο ος func> <format stmt> 
«ma!nÀ exec» 5.ξ «exec stmt» 

y <blox1l imol> «exec stmt» 


| *bloxeé spec» «exec stmt» 
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Sub soec> 


<blok3 data> <exec stmt> 
<matnl impl> <exec stmt> 
<maind soec> «exec stmt» 
<main3 func» «exec stmt» 
main exec?» «exec stmt» 
*«naind exec» «data stmt» 
<main4 exec» «format stmt»? 
«entry stmt» 
«olokl impl?» «entry stmt» 
«ma:nl :mpl» «entry stmt» 
essuelsimpl> «ao! stmt» 
«πι οἱ πο €coarm stet»? 
ΠΕΙ mgl» <formeat sint > 
αυ iM > <ent ry stmt > 


ssave Stmt» 


<blokl 


ADO c 


«oloke 


<mainl 


<maınd 


<maine 


«suol 


<subl 


«sube 


«suoe 


ος 


«S352 


impl» «save stmt» 


SPEC? SS ave TS nt > 


Spec» «entry. stmt» 


)mpi» «save stmt» 


Soec» «save stmt» 


spec> «entry stmt» 


imo, >2<other. spec stmt» 


imol» 


SPEC? 


Spec> 


Spec» 


Spoc» 


«spec stmt» 
save stmt> 
«other spec 
stmt» 


«soec 


<parm stmt» 
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EcuUub5 func» : 


«sub4 exec» : 


«sub5 return»? 


= - 


«subo spec» «format stmt» 
<sube spec> «entry stmt» 
οσο ο mpli-Eestmtfunc stmt» 
<suol impl> «data stmt»? 
«suba spec?» <stmtfunc stmt» 
<sude spec» «data stmt» 
«blok5 data» «entry stmt»? 
*«main$ó func» «entry stmt? 
«ο ον πο «ο πο υπο stmt» 
ο ο ἵσρου “<Gata stnt> 
cM SNP uUNCoU«format stmt» 
Sins func? «entry sStmt» 
«subl imol» «exec stmt»? 
<sutce spec> <exec stmt> 
«suo 5 func» «exec stmt» 
<main4d exec?» «entry stmt» 
<suo4 exec? «exec stmt» 
«suba exec» «oata stmt»? 
“suodwexec> <format stmt> 
<suo4 exec?» «entry stmt» 
Q2. 0spetunn stmt»? 
' <blokl impl> «return stmt» 
See EE EECHER stmt» 
ı <plok3 data> «return stmt» 


' <mainl Impl> «return stmt» 


<maine spec> <return stmt> 


πο fumes s«peturn stmt > 
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1 main exec? «return stmt»? 
|! «subl imol» «return stmt» 

! «suo? spec?» «return stmt»? 

ο σου Όπου Sreturn stmt> 

| *supü exec»? «return stmt» 
ΡΞ. γοσμεη»; «return stmt» 
μι’. τετιαπη» «exec stmt^ 
eS uba return> <oata stmt> 

| *«supS return^ «format stmt» 
ı *suc^5 return?» «entry stmt» 
«dimen stmt» 

“common, Stet > 

<equiv stmt» 


<type stmt» 


«other spec stmt» ::- «external stmt» 


«exec stmt»? 


- 
= 


.πεετίπεῖς οἵπερ 

<assicn stmt» 
Sootostmte 
<arithif stmt> 
<logif stmt> 
«do stmt»? 
<continue stmt»? 
SS Of sumt> 
epouse stmt» 
«read stmt» 
«write stmt» 


εροσιω EE 


6] 





<rewind stmt> 
<backspace stmt? 
<endfile stmt> 
«open stmt» 
«close stmt» 
«1nquire stmt» 


«call stmt» 


AR 
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